PPM build servers are dead -- long live PPM!

Our PPM build server infrastructure has been very maintenance
intensive; it needed some manual tweaking and fixing on a weekly
basis. We finally couldn't stand doing it any longer and turned them
off a couple of weeks ago. The PPM repositories are still there, but
they are not being updated anymore.

But fear not! We took the time saved from having to do all the build
monitoring and fixing and started writing a new simplified build
system that avoids many of the problems the old one runs into.

We have built test repositories for 32-bit ActivePerl 5.10 on Windows
and Linux and would welcome any feedback from people willing to
beta-test them. They are currently being hosted at:

http://ppm.activestate.com/beta

There you'll find additional information about configuring them as
your default PPM4 repositories. It contains links to the build-status
tables at the bottom (one per letter), e.g.

http://ppm.activestate.com/beta/idx/W.html

If you are a CPAN author then you will also want to check the status
page listing all the modules from your CPAN directory, e.g.

http://ppm.activestate.com/beta/author/GAAS.html

We are interested in feedback, especially regarding:

* Do you experience any problems with either the commandline or the
GUI PPM client with these new repositories?

* Do the modules installed from these repositories work properly on
your system? Did they fetch all necessary prerequisites?

* If you are a module author and your module did not build or test
properly: do the build logs contain sufficient information to
understand _why_ they were not being built?

* Is there any information that you would like to see in the build
status results? What is it, and what do you need it for?

Please send your feedback to the PPM mailing list at

mailto:ppm@activestate.com

or enter a bug report in our bug database (use "ActivePerl" product
and "PPM_Server" component):

http://bugs.activestate.com/enter_bug.cgi?product=ActivePerl

Here are a couple of known issues that we are already aware of:

* Some packages contain additional files that are not needed (and
ignored) by the PPM client (HTML documentation, debugging symbols).
This has already been fixed in the build system and all packages
build during the last few days should already have these additional
files stripped.

* Modules bundled with ActivePerl use static linking for all non-
standard additional libraries. E.g. Crypt-SSLeay does not require
that libssl32.so or libssl32.dll is installed as well. This makes
it easier to bundle these modules with packagers like PAR, PerlApp
or Perl2exe, and also avoids putting additional DLLs on the PATH
where they might conflict with different versions of the same DLLs
from other applications.

For all modules bundled by ActivePerl (and for some additional
popular modules we have defined on our internal "watchlist") we want
to make sure the PPM packages will also use statically linked
libraries. This has not been done yet, so especially the Linux
packages may include references to locally installed additional
libraries (libz.so, libgd.so etc).

* The layout of the build status information is preliminary and hasn't
been reviewed by a web-designer yet.

The ActivePerl Team


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: PPM build servers are dead -- long live PPM!

The new PPM repositories are now the default repositories for all PPM4
releases (ActivePerl build 818 and later for Perl 5.8, all builds of
ActivePerl 5.10). There is nothing you have to do to enable them; they
have been moved on the server side to replace the old repos.

There are significantly more modules available for all platforms now,
including a full complement of 64-bit modules for Perl 5.10 (with the
Solaris 64-bit build limping behind a little bit).

If you find any problems, or have any kind of feedback, please file
a bug, send email to the PPM mailing list, or let me know directly.

Cheers,
-Jan

PS: If for whatever reason you need to refer back to the old repository
build status tables, they are still accessible through this link:

http://ppm.activestate.com/index.html

Those repositories and tables are "static" and unsupported and only
exist to allow exploratory work in case a module used to be included
in the old repo but didn't build for the new one.

On Sun, 22 Jun 2008, Jan Dubois wrote:
>
> Our PPM build server infrastructure has been very maintenance
> intensive; it needed some manual tweaking and fixing on a weekly
> basis. We finally couldn't stand doing it any longer and turned them
> off a couple of weeks ago. The PPM repositories are still there, but
> they are not being updated anymore.
>
> But fear not! We took the time saved from having to do all the build
> monitoring and fixing and started writing a new simplified build
> system that avoids many of the problems the old one runs into.
>
> We have built test repositories for 32-bit ActivePerl 5.10 on Windows
> and Linux and would welcome any feedback from people willing to
> beta-test them. They are currently being hosted at:
>
> http://ppm.activestate.com/beta
>
> There you'll find additional information about configuring them as
> your default PPM4 repositories. It contains links to the build-status
> tables at the bottom (one per letter), e.g.
>
> http://ppm.activestate.com/beta/idx/W.html
>
> If you are a CPAN author then you will also want to check the status
> page listing all the modules from your CPAN directory, e.g.
>
> http://ppm.activestate.com/beta/author/GAAS.html
>
> We are interested in feedback, especially regarding:
>
> * Do you experience any problems with either the commandline or the
> GUI PPM client with these new repositories?
>
> * Do the modules installed from these repositories work properly on
> your system? Did they fetch all necessary prerequisites?
>
> * If you are a module author and your module did not build or test
> properly: do the build logs contain sufficient information to
> understand _why_ they were not being built?
>
> * Is there any information that you would like to see in the build
> status results? What is it, and what do you need it for?
>
> Please send your feedback to the PPM mailing list at
>
> mailto:ppm@activestate.com
>
> or enter a bug report in our bug database (use "ActivePerl" product
> and "PPM_Server" component):
>
> http://bugs.activestate.com/enter_bug.cgi?product=ActivePerl
>
> Here are a couple of known issues that we are already aware of:
>
> * Some packages contain additional files that are not needed (and
> ignored) by the PPM client (HTML documentation, debugging symbols).
> This has already been fixed in the build system and all packages
> build during the last few days should already have these additional
> files stripped.
>
> * Modules bundled with ActivePerl use static linking for all non-
> standard additional libraries. E.g. Crypt-SSLeay does not require
> that libssl32.so or libssl32.dll is installed as well. This makes
> it easier to bundle these modules with packagers like PAR, PerlApp
> or Perl2exe, and also avoids putting additional DLLs on the PATH
> where they might conflict with different versions of the same DLLs
> from other applications.
>
> For all modules bundled by ActivePerl (and for some additional
> popular modules we have defined on our internal "watchlist") we want
> to make sure the PPM packages will also use statically linked
> libraries. This has not been done yet, so especially the Linux
> packages may include references to locally installed additional
> libraries (libz.so, libgd.so etc).
>
> * The layout of the build status information is preliminary and hasn't
> been reviewed by a web-designer yet.
>
> The ActivePerl Team
>
>
> _______________________________________________
> PPM mailing list
> PPM@listserv.ActiveState.com
> http://listserv.ActiveState.com/mailman/listinfo/ppm

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PPM build servers are dead -- long live PPM!

Jan Dubois wrote:
> There are significantly more modules available for all platforms now,
> including a full complement of 64-bit modules for Perl 5.10 (with the
> Solaris 64-bit build limping behind a little bit)

One major problem I can see so far is that DBD-mysql isn't building.
This will be crippling to many perl scripts, particularly web scripts.
Bundle-DBD-mysql isn't even attempted.

Seems it can't find mysql.h, is mysql installed on the build machine?
Looks like it needs to be.

On further inspection of my local copy of mysql, mysql.h is found in:-
C:\Program Files\MySQL\MySQL Server 5.0\include\

I'd say this is quite critical, DBD-mysql was available from the old
repository.


Lyle
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PPM build servers are dead -- long live PPM!

Lyle wrote:

> I'd say this is quite critical, DBD-mysql was available from the old
> repository.

DBD-mysql for 5.6/5.8/5.10 is always available from Randy's repository:

http://cpan.uwinnipeg.ca/dist/DBD-mysql

--
Serguei Trouchelle
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PPM build servers are dead -- long live PPM!

Serguei Trouchelle wrote:
> Lyle wrote:
>
>> I'd say this is quite critical, DBD-mysql was available from the old
>> repository.
>
> DBD-mysql for 5.6/5.8/5.10 is always available from Randy's repository:
>
> http://cpan.uwinnipeg.ca/dist/DBD-mysql

I know. But it would seem an important enough module to be in
ActiveStates main archive.


Lyle
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: PPM build servers are dead -- long live PPM!

On Mon, 10 Nov 2008, Lyle wrote:
> >> I'd say this is quite critical, DBD-mysql was available from the old
> >> repository.
> >
> > DBD-mysql for 5.6/5.8/5.10 is always available from Randy's repository:
> >
> > http://cpan.uwinnipeg.ca/dist/DBD-mysql
>
> I know. But it would seem an important enough module to be in
> ActiveStates main archive.

We'll be looking into it.

Cheers,
-Jan

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: PPM build servers are dead -- long live PPM!

Hi,

Do I need to configure a new address to the new repository in order to be able to install modules from it?

If I remember well, DBD-Oracle could be installed from the old repository... or it was just a plan?

Thanks.

Octavian

----- Original Message -----
From: "Jan Dubois"
To: "'Lyle'" ; "'Serguei Trouchelle'"
Cc:
Sent: Tuesday, November 11, 2008 3:51 AM
Subject: RE: PPM build servers are dead -- long live PPM!


> On Mon, 10 Nov 2008, Lyle wrote:
>> >> I'd say this is quite critical, DBD-mysql was available from the old
>> >> repository.
>> >
>> > DBD-mysql for 5.6/5.8/5.10 is always available from Randy's repository:
>> >
>> > http://cpan.uwinnipeg.ca/dist/DBD-mysql
>>
>> I know. But it would seem an important enough module to be in
>> ActiveStates main archive.
>
> We'll be looking into it.
>
> Cheers,
> -Jan
>
> _______________________________________________
> ActivePerl mailing list
> ActivePerl@listserv.ActiveState.com
> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: PPM build servers are dead -- long live PPM!

On Mon, 10 Nov 2008, Octavian Rasnita wrote:
> Do I need to configure a new address to the new repository in order to
> be able to install modules from it?

No, you don't. The ppm4 URLs point to the new repositories now.

> If I remember well, DBD-Oracle could be installed from the old
> repository... or it was just a plan?

Yes, DBD-Oracle is not (yet) in the new repositories, but it is already
bundled with ActivePerl (Windows and Linux 32-bit only).

Cheers,
-Jan

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Reading hash arrays in the order it was written

Hello! The problem I am having is I am pulling data from a table in a
certain order and loading it into the hash array but when I read the
hash array it comes out in a different order than it is written. What I
have done as a work around, is the read the data from a file that has it
in the correct order. Is there away to build the hash so that it reads
in the order it was created?



Key creation and hash build:
select statement ordering by certain columns
......

$key = sprintf("%04d%07d%07d",$chk_num,$trans_seq,$dtl_seq);
$midtlinfo{$key} =
sprintf("%d|%d|%s|%d|%d|%d|%d|%d|%d|%d|%d|%d|%d|%d|%s|%s|%d| %d|%0.2f|%0.
2f|%0.2f",
$se_chk_mi_seq,
$obj_num,
$business_date,
$chk_num,
$trans_seq,
........
);

Reading of the hash:
foreach $mk (keys %midtlinfo)
@mrec = split(/\|/,$midtlinfo{$mk});

....

}

David Fish
Senior Systems Analyst
Property Systems Services
Work (301) 380-3331
Fax (301) 644-7521
BlackBerry (301) 646-8985
david.fish@marriott.com
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: Reading hash arrays in the order it was written

Fish, David wrote:

>> Hello! The problem I am having is I am pulling data from a table
>> in a certain order and loading it into the hash array but when I
>> read the hash array it comes out in a different order than it is
>> written. What I have done as a work around, is the read the data
>> from a file that has it in the correct order. Is there away to
>> build the hash so that it reads in the order it was created?

perldoc -q "hash remember the order"
How can I make my hash remember the order I put elements into it?
Use the "Tie::IxHash" from CPAN.

use Tie::IxHash;

tie my %myhash, 'Tie::IxHash';

for (my $i=0; $i<20; $i++) {
$myhash{$i} = 2*$i;
}

my @keys = keys %myhash;
# @keys = (0,1,2,3,...)

--
Henry Hartley
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: Reading hash arrays in the order it was written

Fish, David <> wrote:
> Hello! The problem I am having is I am pulling data from a table in
> a certain order and loading it into the hash array but when I read
> the hash array it comes out in a different order than it is written.
> What I have done as a work around, is the read the data from a file
> that has it in the correct order. Is there away to build the hash so
> that it reads in the order it was created?
>
>
>
> Key creation and hash build:
> select statement ordering by certain columns
> ......
>
> $key = sprintf("%04d%07d%07d",$chk_num,$trans_seq,$dtl_seq);
> $midtlinfo{$key} =
>
sprintf("%d|%d|%s|%d|%d|%d|%d|%d|%d|%d|%d|%d|%d|%d|%s|%s|%d| %d|%0.2f|%0.
> 2f|%0.2f",
> $se_chk_mi_seq,
> $obj_num,
> $business_date,
> $chk_num,
> $trans_seq,
> ........
> );
>
> Reading of the hash:
> foreach $mk (keys %midtlinfo)
> @mrec = split(/\|/,$midtlinfo{$mk});
>
> ....
>
> }

1. Push keys into an array as you add them to the hash and use that
instead of 'keys %hash',

.... or ...

2. Use the module designed for that purpose. See
http://search.cpan.org/~gsar/Tie-IxHash-1.21/lib/Tie/IxHash. pm

HTH

--
Brian Raven

------------------------------------------------------------ -----------------------------------------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Reading hash arrays in the order it was written

Hi,

I think the key's of the midtlinfo hash are not seen/get in the order you have populated it before, if iam not wrong. If so then a customized compare func could applied (on same terms when ordering by certain columns from tbl was done) while reading from the hash.


Cheers/


--- On Wed, 11/19/08, Fish, David wrote:

> From: Fish, David
> Subject: Reading hash arrays in the order it was written
> To: activeperl@listserv.activestate.com, perl-win32-users@listserv.ActiveState.com, ppm@listserv.ActiveState.com
> Date: Wednesday, November 19, 2008, 9:27 PM
> Hello! The problem I am having is I am pulling data from a
> table in a
> certain order and loading it into the hash array but when I
> read the
> hash array it comes out in a different order than it is
> written. What I
> have done as a work around, is the read the data from a
> file that has it
> in the correct order. Is there away to build the hash so
> that it reads
> in the order it was created?
>
>
>
> Key creation and hash build:
> select statement ordering by certain columns
> ......
>
> $key =
> sprintf("%04d%07d%07d",$chk_num,$trans_seq,$dtl_seq);
> $midtlinfo{$key} =
> sprintf("%d|%d|%s|%d|%d|%d|%d|%d|%d|%d|%d|%d|%d|%d|%s|%s|%d| %d|%0.2f|%0.
> 2f|%0.2f",
> $se_chk_mi_seq,
> $obj_num,
> $business_date,
> $chk_num,
> $trans_seq,
> ........
> );
>
> Reading of the hash:
> foreach $mk (keys %midtlinfo)
> @mrec = split(/\|/,$midtlinfo{$mk});
>
> ....
>
> }
>
> David Fish
> Senior Systems Analyst
> Property Systems Services
> Work (301) 380-3331
> Fax (301) 644-7521
> BlackBerry (301) 646-8985
> david.fish@marriott.com
> _______________________________________________
> ActivePerl mailing list
> ActivePerl@listserv.ActiveState.com
> To unsubscribe:
> http://listserv.ActiveState.com/mailman/mysubs




_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Reading hash arrays in the order it was written

Hi David,

> The problem I am having is I am pulling data from a table in a
> certain order and loading it into the hash array but when I read the
> hash array it comes out in a different order than it is written.

When you need order and iterating, but no random access, use ARRAYs.
When you need key-based random access, but no order, use HASHes.

>From what you tell us, you do not need key-based access,
so do not use a hash in the first place.

> Key creation and hash build:

If you need the key for anything (which is not even clear from what
you tell us), add it to the front of your entry string.
Then push the entry strings onto an ARRAY.

> Reading of the hash:

Just iterate the ARRAY.


Besides, your sequence
- select [database?] statement
- linewise sprintf into CSV-like format
- split while iterating
looks conspiciously like it might be bad design in the first place,
unless there is something you didn't tell us.
If you have data in structured form and need it in
structured form, keep it in structured form, don't
encode it in CSV and decode it right afterwards.


I strongly disagree with the statement "use Tie::IxHash"
made by other contributors. Of course, you should not
reinvent the wheel when you need a wheel, but you should not
use non-standard packages either - unless you really need them.
Maintenance will be easier the less bloat you rely on.

When you really need order *and* key-based access, Tie::IxHash
might be an option. But be sure not to hide bad design by
pulling in overdressed tools.

Yours,
Ingo

--
Ingo Schwarze | Software Engineer | Framework Team
Astaro AG | www.astaro.com | 76227 Karlsruhe | Germany
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Reading hash arrays in the order it was written

Fish, David wrote:
> Hello! The problem I am having is I am pulling data from a table in a
> certain order and loading it into the hash array but when I read the
> hash array it comes out in a different order than it is written. What I
> have done as a work around, is the read the data from a file that has it
> in the correct order. Is there away to build the hash so that it reads
> in the order it was created?
Wouldn't a stack (essentially just an array) be better than a hash?
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Reading hash arrays in the order it was written

--===============0152721923==
Content-Type: multipart/alternative; boundary="0-1708769985-1227196006=:96043"

--0-1708769985-1227196006=:96043
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,
 
The module "Tie::Hash" might be one of the solutions that you are looking f=
or.
 
Regards,
G. Indragoby.

--- On Wed, 19/11/08, Fish, David wrote:

From: Fish, David
Subject: Reading hash arrays in the order it was written
To: activeperl@listserv.activestate.com, perl-win32-users@listserv.ActiveSt=
ate.com, ppm@listserv.ActiveState.com
Date: Wednesday, 19 November, 2008, 9:27 PM

Hello! The problem I am having is I am pulling data from a table in a
certain order and loading it into the hash array but when I read the
hash array it comes out in a different order than it is written. What I
have done as a work around, is the read the data from a file that has it
in the correct order. Is there away to build the hash so that it reads
in the order it was created? =20

=20

Key creation and hash build:
select statement ordering by certain columns
......
=20
$key =3D sprintf("%04d%07d%07d",$chk_num,$trans_seq,$dtl_seq);
$midtlinfo{$key} =3D
sprintf("%d|%d|%s|%d|%d|%d|%d|%d|%d|%d|%d|%d|%d|%d|%s|%s|%d| %d|%0.2f|%0.
2f|%0.2f",
$se_chk_mi_seq,
$obj_num,
$business_date,
$chk_num,
$trans_seq,
........
);

Reading of the hash:
foreach $mk (keys %midtlinfo)
@mrec =3D split(/\|/,$midtlinfo{$mk});

....

}

David Fish
Senior Systems Analyst
Property Systems Services
Work (301) 380-3331
Fax (301) 644-7521
BlackBerry (301) 646-8985
david.fish@marriott.com
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
=0A Be the first one to try the new Messenger 9 Beta! Go to http=
://in.messenger.yahoo.com/win/
--0-1708769985-1227196006=:96043
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

New dev platform running Vista x64; now I"m totally lost!

I tried installing ActivePerl 5.10 back toward the beginning of the year,
but immediately reverted to 5.8 because I didn't have time to build
everything that was missing from PPM just to keep my production software
working.

Just this week I received what is intended to become my new development
platform, a Lenovo ThinkPad W500 with 8GB RAM running Windows Vista Business
x64 SP1. I blissfully installed ActivePerl-5.8.8.824-MSWin32-x64-287188,
expecting my development life to become even more joyful than
before...WRONG!

First off, I had to re-learn PPM command line arcanities since there is no
PPM GUI for x64. Then, once I had gotten back into the command line groove,
all of the repositories I've used in the past -- including ActiveState's,
which at least appears to be adjusted to look for 64-bit packages given its
URL: "http://ppm4.activestate.com/MSWin32-x64/5.8/824/package.xml " (does
"MSWin32-x64" seem oxymoronic to anyone besides me?) -- return zero
available packages.

So where do I go from here in order to waste the minimum amount of time? Am
I doing something wrong in PPM regarding the repositories? Should I install
5.8 32-bit? Should I try 5.10 64-bit? Perhaps I'm setting the bar too
high, but I would very much like to have my development cake and eat it
too....

Thank you,

-Brian


-----Original Message-----
From: activeperl-bounces@listserv.ActiveState.com
[mailto:activeperl-bounces@listserv.ActiveState.com] On Behalf Of Jan Dubois
Sent: Monday, November 10, 2008 11:29
To: activeperl@listserv.ActiveState.com;
perl-win32-users@listserv.ActiveState.com; ppm@listserv.ActiveState.com
Subject: RE: PPM build servers are dead -- long live PPM!

The new PPM repositories are now the default repositories for all PPM4
releases (ActivePerl build 818 and later for Perl 5.8, all builds of
ActivePerl 5.10). There is nothing you have to do to enable them; they
have been moved on the server side to replace the old repos.

There are significantly more modules available for all platforms now,
including a full complement of 64-bit modules for Perl 5.10 (with the
Solaris 64-bit build limping behind a little bit).

If you find any problems, or have any kind of feedback, please file
a bug, send email to the PPM mailing list, or let me know directly.

Cheers,
-Jan

PS: If for whatever reason you need to refer back to the old repository
build status tables, they are still accessible through this link:

http://ppm.activestate.com/index.html

Those repositories and tables are "static" and unsupported and only
exist to allow exploratory work in case a module used to be included
in the old repo but didn't build for the new one.

On Sun, 22 Jun 2008, Jan Dubois wrote:
>
> Our PPM build server infrastructure has been very maintenance
> intensive; it needed some manual tweaking and fixing on a weekly
> basis. We finally couldn't stand doing it any longer and turned them
> off a couple of weeks ago. The PPM repositories are still there, but
> they are not being updated anymore.
>
> But fear not! We took the time saved from having to do all the build
> monitoring and fixing and started writing a new simplified build
> system that avoids many of the problems the old one runs into.
>
> We have built test repositories for 32-bit ActivePerl 5.10 on Windows
> and Linux and would welcome any feedback from people willing to
> beta-test them. They are currently being hosted at:
>
> http://ppm.activestate.com/beta
>
> There you'll find additional information about configuring them as
> your default PPM4 repositories. It contains links to the build-status
> tables at the bottom (one per letter), e.g.
>
> http://ppm.activestate.com/beta/idx/W.html
>
> If you are a CPAN author then you will also want to check the status
> page listing all the modules from your CPAN directory, e.g.
>
> http://ppm.activestate.com/beta/author/GAAS.html
>
> We are interested in feedback, especially regarding:
>
> * Do you experience any problems with either the commandline or the
> GUI PPM client with these new repositories?
>
> * Do the modules installed from these repositories work properly on
> your system? Did they fetch all necessary prerequisites?
>
> * If you are a module author and your module did not build or test
> properly: do the build logs contain sufficient information to
> understand _why_ they were not being built?
>
> * Is there any information that you would like to see in the build
> status results? What is it, and what do you need it for?
>
> Please send your feedback to the PPM mailing list at
>
> mailto:ppm@activestate.com
>
> or enter a bug report in our bug database (use "ActivePerl" product
> and "PPM_Server" component):
>
> http://bugs.activestate.com/enter_bug.cgi?product=ActivePerl
>
> Here are a couple of known issues that we are already aware of:
>
> * Some packages contain additional files that are not needed (and
> ignored) by the PPM client (HTML documentation, debugging symbols).
> This has already been fixed in the build system and all packages
> build during the last few days should already have these additional
> files stripped.
>
> * Modules bundled with ActivePerl use static linking for all non-
> standard additional libraries. E.g. Crypt-SSLeay does not require
> that libssl32.so or libssl32.dll is installed as well. This makes
> it easier to bundle these modules with packagers like PAR, PerlApp
> or Perl2exe, and also avoids putting additional DLLs on the PATH
> where they might conflict with different versions of the same DLLs
> from other applications.
>
> For all modules bundled by ActivePerl (and for some additional
> popular modules we have defined on our internal "watchlist") we want
> to make sure the PPM packages will also use statically linked
> libraries. This has not been done yet, so especially the Linux
> packages may include references to locally installed additional
> libraries (libz.so, libgd.so etc).
>
> * The layout of the build status information is preliminary and hasn't
> been reviewed by a web-designer yet.
>
> The ActivePerl Team
>
>
> _______________________________________________
> PPM mailing list
> PPM@listserv.ActiveState.com
> http://listserv.ActiveState.com/mailman/listinfo/ppm

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: New dev platform running Vista x64; now I"m totally lost!

On Fri, 12 Dec 2008, Brian H. Oak wrote:
> I tried installing ActivePerl 5.10 back toward the beginning of the year,
> but immediately reverted to 5.8 because I didn't have time to build
> everything that was missing from PPM just to keep my production software
> working.

You may want to try 5.10 again; the ActiveState PPM repos have been completely
rebuild using a new build system and should be a lot more comprehensive now.

Combined with the additional repositories at Uwinnipeg and Trouchelle you
should get a pretty complete set of modules that actually build on Windows
at all.

> Just this week I received what is intended to become my new development
> platform, a Lenovo ThinkPad W500 with 8GB RAM running Windows Vista Business
> x64 SP1. I blissfully installed ActivePerl-5.8.8.824-MSWin32-x64-287188,
> expecting my development life to become even more joyful than
> before...WRONG!
>
> First off, I had to re-learn PPM command line arcanities since there is no
> PPM GUI for x64. Then, once I had gotten back into the command line groove,
> all of the repositories I've used in the past -- including ActiveState's,
> which at least appears to be adjusted to look for 64-bit packages given its
> URL: "http://ppm4.activestate.com/MSWin32-x64/5.8/824/package.xml " (does
> "MSWin32-x64" seem oxymoronic to anyone besides me?) -- return zero
> available packages.

("MSWin32" is the API. Note that even Microsoft refers to it as the
"Win32 API for Windows 64". "x64" is used to designate the 64-bit
version of Windows, "x86" being the 32-bit one. You can run the "x86"
version just fine on 64-bit Windows too.)

The problem is that there is no 64-bit repository for Perl 5.8, there is
only one for 5.10 (there used to be an experimental one for 5.8 in the
past, so maybe some redirect has gone missing, but that repository was
rather small and is no longer being updated anyways).

> So where do I go from here in order to waste the minimum amount of time? Am
> I doing something wrong in PPM regarding the repositories? Should I install
> 5.8 32-bit? Should I try 5.10 64-bit? Perhaps I'm setting the bar too
> high, but I would very much like to have my development cake and eat it
> too....

There are several options for you:

* You can run the 32-bit (x86) builds of ActivePerl on your 64-bit
Vista, either 5.8 or 5.10. Those give you maximum coverage of PPM
repositories and the PPM GUI.

The disadvantage are that you are running in the WOW64 (Windows on
Windows 64) subsystem, which means part of the file system and registry
will be redirected; your Perl applications will not be able to touch
some 64-bit only areas of the machine.

* You can run the 64-bit Perl 5.10 build. This will give you the full
ActiveState repository, but there are no additional repos for the
modules that require human intervention to build successfully. You
will also have to use the PPM commandline, but that may change in
the next release or so because we should have working 64-bit tkkits
for Tkx now.


Check here to see how many modules are available for each architecture
right now:

http://ppm4.activestate.com/

Cheers,
-Jan

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: New dev platform running Vista x64; now I"m totally lost!

On Sat, 13 Dec 2008, Brian H. Oak wrote:
> Thank you for all of your help so far. Per your suggestion I
> uninstalled 5.8 and loaded 5.10 64-bit, and was quite pleased with the
> PPM coverage. Unfortunately, I have found two deal-breakers:
> Win32::API and Win32::API::Prototype. There are some others missing,
> but only these two will break my mainline software.
>
> Would some kind soul, pretty please, (1) build these packages manually
> and post them on the ActiveState repository, (2) suggest alternate
> packages or a workaround that would obviate my need for these, or (3)
> point me to the resources and instructions necessary for me to build
> these packages manually on my own?

Win32::API and Win32::API::Prototype actually need to be "ported" to
64-bit Windows as they deal with calling arbitrary functions in DLLs,
and the current code assumes 32-bitness, calling conventions, etc. It
also contains inline assembly code, IIRC, which isn't supported by the
64-bit compilers. I believe Cosimo is interested in porting the code
to work under 64-bit Windows, but hasn't actually done any work on it
so far.

It is not really possible to suggest alternatives to these modules
without knowing what you are using them for, as they are only
providing the glue to calling arbitrary code in other DLLs.

If you cannot live without Win32::API then you'll need to run
32-bit Perl for now.

Note also that even with a 64-bit version of Win32::API you won't
be able to call code in 32-bit DLLs; you can only call 64-bit code
inside a 64-bit process, so whatever you are accessing needs to
provide 64-bit DLLs as well.

> I believe that I don't even have a Win32 C compiler lying around
> anymore. I remember from a few years ago (the last time I actually
> rolled my own PPM packages) that I compiled my packages using v7 of
> Microsoft's compiler, while ActiveState was using the v6 compiler.
> This slight difference sometimes made it iffy to mix my packages with
> theirs. If I have to start making my own packages again, I would like
> all the details on how to do it right from the beginning....

ActivePerl is still compiled with VC6 for various reasons; the
recommended compilers for building extensions are VC6 and MinGW. For
most extensions there should be no problem if you build them with a
later VC version. If you use these modules with PerlApp/Perl2exe/PAR
then you will need to package and auto-extract the additional runtime
libraries for those compilers too (which is one of the reason for
sticking with VC6 or GCC).

I plan to build a PPM package for MinGW by the end of the year, so that
you can install GCC with just `ppm install MinGW` or similar.

All the above is for the 32-bit builds. 64-bit ActivePerl is built with
the VC compiler from the Windows 2003 Platform SDK, and extensions
should be built using the same compiler to make sure they reference the
64-bit version of MSVCRT.dll that is part of all 64-bit Windows releases
and not a compiler specific runtime.

> One last question, almost totally off-topic: should I have any
> problems getting PerlApps built on a Windows 64-bit system to run on a
> 32-bit system?

Assuming you use the 32-bit ActivePerl and 32-bit PerlApp there should
be no problems. The 64-bit executables generated by the 64-bit PerlApp
will not run on 32-bit Windows; it only works the other way around
(32-bit code can be executed on 64-bit Windows using the WOW64
subsystem).

Cheers,
-Jan

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs